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Field of the Invention 

,00021 The invention .^lates to dato processing by a digital computer, and more 
rra:;toso,tw<.earchitec..esf.computeropp.ca..nsbuiltonplat,orms 

such as Java 2 Enterprise Edition and Microsoft® .net. 

Background of the Invention 

(00031 Object-oriented programming languages such as Java 2 Enterprise 
« „ ,J EE, and Microsott® .net provide businesses ^th pov^erful tec n,ca, 
Itructues Ihey con use to build distributed enterprise busine« aPp.catK>ns. 
unfortunately, the lock of predefined organtotion within these technical 
Istructures causes applications ^tten on these platforms to be unnec«»* 
*mplex and inconsistenl. This leads to a variety o, problems in deve^p,,^ and 
:urIropP«cations .hat are not addressed by existing too. and techno.g,es. 
100041 one Of the problen. w»h known technical infrastructures for dislributed 

nterlrise bu^ness app«cat,ons is that they al^w unstructured P'°«;-^^ 
wHtlen. Programmers Who code busine»app«cat»r.««ortenv..eaprogram 
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o„.c«co,.«-onsopp.cor.n.conno,^eo*c.o^^^^ 
,e,u«.en. ao^erge or when prober™ ore encountered The ^c^ 
««y olso increose, costs ossocWed «.h ony .e=hn.o, change. 

,0007, Accadingly. .here is a need ,or n.e,hods or so«wore .ho. oddre«es .he 
re:L,oneVo«e...oossls,.ogro..ers:ncrea..^^^^^^ 

*.nbu.ed en.erpnse business app.ico.ions on ^^^^"^""'f"''^^^ 
lp,en,en«ng ob,ec.-orten.ed methods such as J2EE and M,aosoH^ .ne.. 

Summary of the Invention 
,000s, The,nven,.nisaso«wareo,ch»ec..e.ha.providesabridge^^^^^^ 
o, Jore app«co.ion and under^ng .echoica, in.as.ruc,ure. e s^o- 

rrcK,.ec.ure orgontos .he app,ica«on in.o a se. o. reuso«e 
::cesin,pie.en.edw»h™r„gerobiec.sondodap.erob..s^^^^^^ 

.unCionoii^ speci-ic .o .he so«wore oppiicotion is 
opplicCion componen.s. The h^nager o^ecU ore ,ns.ohces o'^'^^ 
Inoger Cosses and .he odop.er obiec. are ins.onces o. provided adop.e. 
TL! Whenaso,Wvoreopp«co.ionco,is,n,o.heso.Vareorch,.ec,ure 

^roh a specific arch,.ec.ure service .o reques. funCionoliW. a manager 
!Z or service isins.on.io.ed.orece.e,heca,,. The manager o^^^^^ 

n^In.io.es the appropHo.e odop.er o^ec. ond de,ega.es ,he ca« .o , a, 
airoblec..Theodop.erobiec.ins.on.io.es,heoppropno.eopp,.a.,on 

componen.s to provide .he funCionoiily reques.ed in the coli. 

,00091 The soflwore archi.ec.ure o. .he inven«on is composed o. o p,uro,i.y o. 

Sec.urrse,vices, .needing o nav.go«on se^ice, a business process se^ce. 
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application functionality for each ^>ce to be developed 

other services. 

Description of the Drawir^gs 

,00,0, Hsura 1 A iil.*otes a convent„nal P..ne» opp^otlon built d.ec.. on o 
technical infrastructure. 

,00, ,1 figure ,B illustrates a softwore archUecture that provides a bridge 
'™ o business appilcotion and the underVing technical Introstructure. 
,C„,2, Pigure2isanobstrac.«lus,ratlono.thesoftwarea,chi,ectureo,.he 

invention. 

,00,3, figure 3 Is a UML figure o, the software orchitacture of the invention. 
,00, 41 Figure 4 illustrates code for a monoger conflguration tile. 

,00,5, ngure 5 iliustrotes code lor an odoptar configuration ffle. 

,00, 6, Figure 6 illus^otas o softwore architecture tho, includes a plurollty o. 

architecture services. 

,00,7, Figure 7 Is o UML figure of o no^gotlon orchBecture service. 
,00,8, F^uraS.o UMLtigureoto business process architecture san^e. 

,00,9, Figure 9 is o UML figure of a persistence orchitacture service. 
,00201 Figure ,0 is a UML flgure of o logging architecture service. 
,C02„ Figure „ isoUMLfigureo, Oh application state management 

architecture service. 

,00221 Figure ,2.o UML figure of a data marshaling architecture service. 
,0023, Figure ,3 Is o UML figure of a key management orchHacture sen^a. 

,0024, F«ure ,4 is a flowchart dasaibing how a business opplicottoh framewor. 
:^!l":sinassfi.nClohal„yfromthesof.waraarchltectureofthe,nvent,oh. 

,0025, Figure ,5isaflowch«tdescn^ingthaopero«onofthena.ga,lonsa,vlca. 
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100261 Figure , 6 is a flowchart describing .he operation of the business process 
service. 

10027] Figure 1 7 is a flowchart describing the operatlor. of the persistence 
service. 

Detailed Description 

,00281 The invention is a software architecture thot provides struC^e for software 
applications, sep^ates different concerns o, the oppiicotion, ond prov des 
ftexibility that enabtes changes to be mode to softwore applications w,th ease 
rela«ve to conventional applteations. As used herein, the term "convent,onal 
appncation- refers to a software application written without the software 
architecture of the invention. 

100291 The software architecture of the invention deflnes a structure that can be 
used for monv types of software applications, inching but not limited to 
business opplicotions and distributed ente^ise bminess applications ^ dan^, 
business applications ore used herein to describe Implementations of the 
invention. It should be noted, however, thot the invention is not limited to 
business applications. 

[0O3O1 The stmcture ^^ovided by the software architecture of the invention con 
pe v^uafeed as a skeletal support that is used as a basis for building a softwore 
applicotion. The structure defines Intuitive and hofetic software components that 
m m this Skeletal support. These software components are made to be 
independent so each software component can be replaced or amended 
without impocting other software components. This molces debugging and 
modifying o software application an easier task for users. 
,00311 The softwore architecture o, the invention separates different concerns of 
the sothvore applicotion. For instance, users who implement the software 
architecture of the invention to build applications tend to fail into two 
categories: technical pro^ammers and application programmers. Accordingly, 
the software architecture of the invention generally separates technical code 
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li e., technical componen.s| .equ^ed by Ihe technical programmers tram 
Uaf.n.peclfic code (i.e., appllcotlon-spec,«c componenls, rea^jed V 
the applicotion p-ogrammers. Since these software components are gener* 
rr.de to be Independent, changes to one group o. sot^are components tend 
to not impact the other group of software components. 
,00321 The software architecture of the Invention also provides a simplified 
appllcat»n programming interface that exposes func.ional«y necessary to an 
opplfcation programmer bu, encapsulates the complexly of the .echn.a, 
infrastructure. This technical infrastructure can still be exposed to the technrcal 
pro^ammer, or other technical users, outside of this app«catton progrommrng 
interface to modify and generate code to handle technical bsues. 
100331 Addltlonolly, the software architecture of the invention is ftexible and 
configurable to enable a ^ to lmplen,ent changes to a software appl,cat,on 
using methods that are relatively eaSe, than methods used to, ™<^''Vl"9 
conventional applications. In on Implementation of the invention, the sof^«ore 
architecture utlfees adiustable configuration files to provWe functiono«ty that 
would namolly be encoded d^ectly into the software application. Th^ 
configuration files con be eosiV modified as needed by a user to modify the 
behavior of the software appiicatton. The use of a configuration file therefore 
enable the re-use of software components and eliminate ■■hord-codrng of 
pro^ammmg behovic in volotiie areas that ore «.ely to change through the „fe 
of a software application. 

,00341 AS shown In Figure lA, a conventional business application 10 is built 
directs on a technical infrastructure 20. The business application 10 ,s a 
computer program devdoped to caty out business-specific functlonolrty. Th,s 
functionality is implemented using methods developed and coded by o user, 
fa example, a user fam^rar with the business requirements of an enterprise con 
write II e., code) and maintain business-specific logic for a business applrcation 
that the enterprise desires. The underlying technical Infrastnjcture 20 ,s the 
programming longuage plotform used for the business application 10. The 
technical infrastructure 20 is general Implemented on a computer or an 
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application server. In one implementation, the underlying technical 
infrastructure 20 is implemented as a J2EE-compliant or a Microsoft® .net 
compliant application server. Building the business application 10 directly on the 
technical infrastructure 20 results in the business application 10 having technical 
code mixed in vA\h business-specific code, leading to functional intermingling 
that becomes harder to debug and maintain as the business application 10 
grows and matures, and as the business-specific logic changes. 
[0035] Figure 1 B illustrates an implementation of a software architecture 100 
constructed in accordance with the invention that provides a bridge between 
the business application 10 and the underlying technical infrastructure 20. The 
software architecture 100 provides a middleware layer between the business 
application 10 and the technical infrastructure 20 that contains structural code 
generally separating the business application concerns from the technical 
infrastructure concerns, and generally separating business software components 
from technical software components. The software architecture 100 provides a 
framework enabling the business application 10 to interact with the technical 
infrastructure 20 built on a platform such J2EE or Microsoft® .net. 
[0036] Figure 2 illustrates an implementation of the invention where the software 
architecture 100 separates the technical, structural, and architectural 
functionality of a distributed application from its application-specific 
functionality. The technical, structural, and architectural functionality is common 
to all distributed applications and the software architecture 100 implements this 
functionality by providing reusable manager objects 210 and adopter objects 
212, which are described in more detail below. The application-specific 
functionality, which is specific to a particular application, is provided by the 
software architecture 100 using one or more application components 202. 
[0037] The application components 202 are discrete portions of code that 
contain focused functionality specific to the application. For example, if the 
application is a business application, the application components 202 provide 
the actual business functionality. An individual application component 202 
generally focuses on only a particular piece of this functionality. Many 
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application components 202 have no knowledge of the technical environment 
in v\/hich they are running. This allows those application components 202 to be 
greatly independent of their technical environment, enabling them to be reused 
in other parts of the business application or in completely different software 
applications. It should be noted that the application components 202 are 
generated by users of the software architecture 100; they are not provided by 
the software architecture 100. 

[0038] In one implementation of the invention, a business application client 200 
calls into the software architecture 100 to request some business functionality. 
The client 200 is any piece of software that can call into the software 
architecture 100 to make a request. The software architecture 100 uses the 
manager object 210 and at least one adapter object 212 to handle this 
incoming call. The manager object 210 receives and parses the incoming call to 
determine what is being requested by the client 200. The manager object 210 
then selects an adapter object 212 that is configured to handle such a request 
and delegates the call to the selected adapter object 21 2. Each adapter 
object 212 is generally equipped to handle a plurality of tasks. The adapter 
object 212, upon receiving the call, determines what functionality is requested 
and calls the appropriate application components 202 to process the request. 
The use of manager objects 210 and adapter objects 21 2 to handle calls from 
the client 200 and to call application components 202 differs from conventional 
applications where the application code is in control and calls into libraries to 
accomplish certain specialized functions. 

[0039] Figure 3 is a unified modeling language (UML) diagram of the software 
architecture 100. In the implementation shown in Figure 3, the technical 
infrastructure 20 is an object-oriented platform (e.g., J2EE), and the software 
architecture 100 provides at least one manager class 300. The manager class 
300 is used by the software architecture 100 to instantiate a manager object 210. 
The manager class 300 defines all of the properties of the manager object 210, 
and con define functional methods relevant to incoming colls from the client 
200. For instance, the manager class 300 can define a "save" method that is 
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relevant to an incoming call requesting that a data object be stored in a 
database. As one of ordinary skill in \he art will recognize, in object-oriented 
programming, a class is a template definition of the properties and behaviors, 
such as variables and methods, in a particular kind of object. Classes ore used 
to instantiate (i.e., create) objects in memory. Thus, an object is a specific 
instance of a class; it contains real values instead of variables. A class con have 
subclasses that can inherit all or some of the characteristics of the class. In 
relation to each subclass, the class becomes the superclass. Subclasses can also 
define their own methods and variables that are not part of their superclass. The 
structure of a class and its subclasses is called the class hierarchy. 
[0040] In on implementation of the invention, the software architecture 100 
provides a manager configuration 214 that contains configuration data for the 
manager object 210. When a manager object 210 is instantiated, the manager 
object 210 retrieves configuration data from its corresponding manager 
configuration 214. The data in the manager configuration 21 4 provides the 
manager object 210 with methods, rules, and filters to apply to incoming calls 
from the client 200. This includes information specifying which adapter objects 
21 2 to call for different requests from the client 200. A user can modify the 
behavior of a manager object 210 by modifying the manager configuration 214. 
This reduces the need to rewrite code for a manager object 210 or manager 
class simply to modify the behavior of the manager object 210. The manager 
object 210 can respond dynamically to changes in the configuration data 
included in the manager configuration file 21 4. Figure 4 illustrates an 
implementation of a manager configuration file 214, written in J2EE code, for a 
manager object named "PersistenceManager." 

[0041] Returning to Figure 3. in an implementation of the invention, the software 
architecture 100 also provides at least one adapter class 302. The adapter class 
302 is used by the software architecture 100 to instantiate one or more adapter 
objects 212 and defines all of the properties and behaviors of the adapter 
objects 212. As is described below, the software architecture 1 00 can provide a 
separate adapter class 302 for each possible type of adapter object 212. 
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[0042] The adapter objects 212 are pluggable connponents of the software 
architecture 1 00. Since the adapter objects 212 are responsible for calling 
application connponents 202 to process requests, the adapter objects 212 
provide a nnechanisnn for a user, such as a technical programnner, to modify the 
behavior of the software architecture 100. This enables the interaction with the 
technical infrastructure 20 to be changed without nnodifying the manager 
objects 210, the application components 202, or the client 200, but by simply 
modifying the configuration to specify a different adapter object 212. The 
architecture 1 00 provides adapter objects 21 2 for various uses, but also allows 
technical programmers the option of building their own custom adapter object. 
This in turn provides a great amount of technical flexibility. 

[0043] In on implementation of the invention, the software architecture 100 
provides an adapter configuration 216 containing configuration data for the 
adapter objects 212. As is described below, in one implementation there is a 
separate adapter configuration 21 6 for each possible adapter object 21 2. 
When an adapter object 212 is instantiated, it retrieves configuration data from 
the adapter configuration 21 6. 

[0044] The data in the adopter configuration 21 6 provides the adopter object 
21 2 with methods, rules, and filters to apply to incoming colls from the manager 
object 210. This includes information specifying which application components 
202 to coll for different requests from the client 200. A user con modify the 
behavior of the adapter object 21 2 by simply modifying the adopter 
configuration 21 6. The adapter object 212 can respond dynamically to changes 
in the configuration data. Figure 5 illustrates an implementation of an adapter 
configuration 216 for an adapter named "BusinessProcessAdapter" written in 
Java code. 

[0045] Returning again to Figure 3, the software architecture 100 con provide 
one or more interfaces to be used in conjunction with the manager object 210 
and the adapter objects 212. An interface provides templates of behavior that 
objects can implement. In one implementation, the software architecture 100 
provides an adapter interface 304 that enables communications between the 
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manager object 210 and the adapter object 212 to occur. More specifically, 
when the nnanager object 210 instances the adapter object 212, the adapter 
interface 304 provides nnethods to be implennented by the adapter object 212 
so the nnanager object 210 can connnnunicate with the adapter object 212. 

[0046] As is described below, different nnanager objects 210 can be associated 
with different adapter interfaces 304. An adapter object 21 2 innplennented for a 
specific manager object 210 must therefore implement that manager object's 
corresponding adapter interface 304. 

[0047] The software architecture 100 con also provide one or more interfaces to 
be used in conjunction with the adopter objects 212 and the application 
components 202. Similar to the adapter interface 304, in one implementation, 
the software architecture 100 provides an application component interface 306 
that enables communications between the adapter object 212 and the 
application components 202 to occur. The methods of the application 
component interface 306 must be implemented by the application components 
202. An adapter object 212 can then instance an application component 202 
and communicate with that application component 202 after the methods of 
the application component interface 306 have been implemented. 

[0048] Figure 6 illustrates an implementation of the invention where the software 
architecture 100 organizes its functionality into a plurality of architecture services. 
In this implementation, the software architecture 100 includes a navigation 
service 204, a business process service 206, and a persistence service 208. Each 
architecture service includes one manager object 210 and at least one adapter 
object 212 to provide technical, structural, and architectural functionality. 
Accordingly, the software architecture 100 provides a navigation manager class, 
a business process manager class, and a persistence manager class. Each 
architecture service also includes a separate manager configuration 214 for its . 
manager object 210. In other implementations, additional architecture services 
can be included in the software architecture 100 to further organize or increase 
the functionality of the architecture. 
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[0049] The navigation service 204 can handle data communications with an 
end-user of the business application, for instance, through a graphical user 
interface (GUI). The navigation service 204 can display the GUI to an end-user 
and can also control the user interface flow or navigation. The business process 
sen/ice 206 can handle the processing of business logic contained in the business 
application. For example, if the business application is designed to handle 
banking transactions, the business process service 206 can carry out the 
associated banking transaction methods, such as transferring funds between 
accounts. Finally, the persistence service 208 can handle data persistence, such 
as creating, storing, retrieving, modifying, and deleting objects and data. 

[0050] In one implementation, the client 200 initiates a request by calling into the 
navigation service 204 of the software architecture. The navigation service 204 
can route the call to the appropriate service, such as the business process 
service 206 or the persistence service 208. In another implementation, the client 
200 can call directly into the appropriate service it needs (e.g., the business 
process service 206). End-user interactions, however, are generally initiated at 
the navigation service 204. 

[0051] In on implementation of the invention, each application component 202 
is associated with at least one of the services. The software architecture 100 
takes application components 202 containing navigation functionality and 
associates them with the navigation service 204. Likewise, the software 
architecture 100 associates business logic application components 202 with the 
business process service 206, and persistence application components 202 with 
the persistence service 208. 

[0052] In one implementation, each service provided by the software 
architecture 100 can include one or more application component interfaces 306 
to be implemented by the application components 202 associated with that 
service. In an implementation of the invention, each adapter object 212 is 
associated with a specific application component interface 306, and an 
application component 202 instanced and called by that adapter object 212 
can implement that specific application component interface 306. 
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[0053] Users, such as the business programmers described above, generate the 
application components 202 using protocols imposed by the software 
architecture 100 and the relevant architecture service. In one implementation, 
one such protocol is that application components 202 must implement the 
application component interface 306 defined by the relevant architecture 
sen/ice. The service con then coll the application components 202 through that 
application component Interface 306. In an implementation, another such 
protocol is that the application components 202 must be added to the 
configuration 216 for an architectural service in a specified format so that they 
can be read and loaded. The application components 202 of one service can 
be developed independent from the application components 202 of another 
service. As such, different users can develop different application components 
202 independently of each other. 

[0054] The organization of the application components 202 into different sen/ices 
allows users developing portions of a business application to woric within a 
specific service without having to address issues from other sen/ices. So a user 
proficient at developing business logic can generate business logic application 
components 202 without having to address navigation or persistence issues. 
Similarly, a user experienced at developing graphical user interfaces can focus 
on generating navigation application components 202, while a technical user 
familiar with the technical infrastructure can develop the persistence application 
components 202. The software architecture 100 then assembles these different 
application components 202 to form one coherent business application. 

[0055] The manager object 210 is the primary point of interaction for the 
architecture service. Since only one manager object 210 is defined for each 
architecture service, a relatively small number of manager objects 210 exist, 
thereby reducing the complexity of the software architecture 100 from the 
perspective of the client 200. The client 200 can then access the functionality 
contained in the software architecture 100 by simply communicating with the 
small number of manager objects 210. 
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[0056] When the functionality of on architecture service is needed by a user 
coding a client 200, the user need only write code that colls the manager object 
210 associated with the required sen/ice. The user does not have to write code 
that includes the functionality of the service. Thus, the nnanager object 210 
provides an abstraction of the service for the user which simplifies the 
development of a business application. Decision-making processes are handled 
by the manager object 210 once it is called, thereby removing that task from the 
user. The manager object 210 calls an adapter object 212 that encapsulates the 
actual behavior. The manager object 210 communicates with the adapter 
object 21 2 through the adapter interface 304 defined for the relevant 
architectural service. 

[0057] Figure 7 is a UML diagram of one implementation of the navigation 
architecture service 204 provided by the software architecture 100. For this 
Implementation (as well as the implementations described in Figures 8 through 
13). the technical architecture 20 is a J2EE application server. In other 
implementations, however, other technical architectures can be used. It should 
be noted that the names used for the objects discussed in Figures 7 through 13 
below are merely for explanatory purposes and should in no way be construed 
as imposing limitations on the invention. 

[0058] In the implementation of Figure 7, the software architecture 100 provides 
a root class 700 called BaseFrameworkObject 700, which is based on the 
java.lang.Object class provided in the J2EE technical infrastructure. The root 
class 700 can add at least one method to the java.lang.Object class, for 
instance, a method to return the class name for the instance of this object. The 
root class 700 can serve as the root object for all objects used by the software 
architecture 100, which facilitates adding behavior that will be common to all of 
them. This also allows all of the software architecture 100 objects to be 
referenced in a uniform fashion that can be more useful than java.lang.Object, 

[0059] The software architecture 100 provides a manager class 300. called 
BaseManager class 300, which extends the root class 700. The BaseMonoger 
class 300 functions as o superclass for all of the manager classes and facilitates 
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adding behavior that will be common to just the manager objects 210. Using the 
BaseManager class 300, the software architecture 100 instantiates a manager 
object 210 called NavigationManager object 210. The NavigationManager 
object 210 extends the BaseManager class 300 and functions as the manager 
object 210 for the navigation sen/ice 204. The NavigationManager object 210 
can implement one or more methods to process incoming calls, select adapter 
objects 21 2, and delegate calls to the selected adapter objects 21 2. The 
NavigationManager object 210 loads configuration data from the manager 
configuration 214 (referred to here as NavigationManager configuration 214). 

[0060] The software architecture 100 provides an adopter class 302, called 
BoseAdopter class 302, which is also based on the root class 700 (i.e., 
BaseFromeworkObject) provided by the software architecture 100. The 
BoseAdopter class 302 extends the root class 700 and functions as a superclass 
for all of the software architecture 100 adapter classes. The BoseAdopter class 
302 facilitates adding behavior that will be common to just the adapter objects 
212, regardless of the sen/ice in which the adapter object 212 is used. The 
BoseAdopter class 302 implements on interface 702, called FrameworkAdopter 
interface 702, which functions as a superclass for all software architecture 100 
adapter interfaces and facilitates adding behavior that will be common to all of 
them. 

[0061] Next, the software architecture 100 provides o navigation adopter doss 
704, called the BoseNavigotionAdopter doss 704, which extends the 
BoseAdopter class 302 and functions as a superclass for all adapter classes 
associated with the navigation service 204. This BoseNavigationAdopter class 
704 facilitates adding behavior that will be common to just the navigation 
service adapter objects 212. 

[0062] The BoseNovigotionAdapter class 704 implements on adopter interface 
304 called NovigotionAdopter interface 304. This is the adapter interface 304 
specified by the navigation sen/ice 204. The NovigotionAdopter interface 304 
provides methods to be implemented by the BoseNovigotionAdapter class 704 
so that the navigation manager object 210 (i.e., NavigationManager object 210) 
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can communicate with the navigation adapter objects 212 instantiated from the 
BaseNavigationAdapter class 704. In one implementation, the 
NovigotionAdapter interface 304 con add methods to process incoming calls, to 
determine if the cached adapter should be invalidated, and to display a page 
as the response to an end-user. 

[0063] The software architecture 100 instantiates one or more adapter objects 
212 from the BaseNavigationAdapter class 704. In one implementation, as 
shown in Figure 7, a NovigationAdapter object 212 is instantiated from the 
BaseNavigationAdapter class 704. The NovigationAdapter object 212 loads 
configuration data from an adapter configuration file 216, such as the 
NovigationAdapter configuration 216. The NovigationAdapter object 212 can 
use known J2EE interfaces to carry out navigation functionality, for instance, by 
using J2EE application component interfaces 306 such as JSPPage and Servlet. 

[0064] Figure 8 is a UML diagram illustrating one implementation of a business 
process architecture service 206 used in the software architecture 100. Similar to 
the NovigationManoger object 210 in Figure 7, the software architecture 100 
uses the BaseMonoger class 300 to instantiate a manager object 210, in this case 
BusinessProcessMonoger 210, which serves as the manager object 210 for the 
business process sen/ice 206. The BusinessProcessMonoger object 210 con 
execute business processes by looking up the appropriate adopter object 212 to 
handle the business process and then delegating the coll to that adopter object 
212. The BusinessProcessMonoger object 210 loads configuration data from the 
manager configuration 214 (referred to here as BusinessProcessMonoger 
configuration 214). 

[0065] The software architecture 100 also provides business process adapter 
classes for the business process sen/ice 206. Using the BaseAdopter class 302 
described above, the software architecture 100 con provide a 
BoseBusinessProcessAdopter class 800 that extends the BaseAdopter class 302 
and functions as a superclass for all of the adopter objects 21 2 associated with 
the business process service 206. The BoseBusinessProcessAdopter class 800 con 
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access configuration data fronn an adapter configuration file 21 6, such as the 
BusinessProcessAdapter configuration 216. 

[0066] The BaseBusinessProcessAdapter class 800 inaplements an adapter 
interface 304, in this case BusinessProcessAdapter interface 304, as required by 
the business process service 206. The BusinessProcessAdapter interface 304 
provides methods implemented by the business adapter objects 212 to allow the 
business manager object 210 (i.e., BusinessProcessManager 210) to 
communicate with the business adapter objects 212. 

[0067] The BaseBusinessProcessAdapter class 800 also implements an application 
component interface 306, in this case the BusinessProcessStep interface 306. This 
application component interface 306 provides methods enabling the adapter 
objects 21 2 to communicate with application components 202 that contain 
business logic for executing business process steps. For example, an application 
component 202 can be included that contains business logic invoked as part of 
a business process. A business process is the logical grouping of a sequence of 
steps. 

[0068] The software architecture 100 can provide a BusinessProcessAdapter class 
(not shown) that extends the BaseBusinessProcessAdapter class and contains 
most of the default behavior for the adapter objects 21 2 used in the business 
process sen/ice 206. The adapter objects 212 can then be instantiated from 
either the BaseBusinessProcessAdapter class 800 or the BusinessProcessAdapter 
class, depending on the functionality required. 

[0069] Finally, because there is specialized behavior for adapter objects 212 that 
interface with HTTP requests (e.g., over the Internet) or with Enterprise Java Beans 
(EJB), separate objects can be provided for these functions. As shown in Figure 
8, the software architecture 100 instantiates a WebBusinessProcessAdapter 
object 212 and an E J BBusinessProcess Adapter object 212. Incoming HHP calls 
are handled by the WebBusinessProcessAdapter object 212, while ELB calls are 
handled by the EJBBusinessProcessAdapter object 21 2. These are just two of the 
many possible adapter objects 212 that can be implemented by the business 
process service 206. 
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[0070] Figure 9 is a UML diagram illustrating one innplennentation of a persistence 
architecture service 206 used in thie software architecture 100. In this 
implementation, the software architecture 100 uses the BaseManager class 300 
to instantiate a manager object 210 for the persistence service 208 referred to as 
the PersistenceManager object 210. The PersistenceManager object 210 can 
use adapter objects 21 2 to carry out methods for interacting with the persistence 
mechanism, such as a database, an extensible markup language (XML) file, or 
other storage devices. The PersistenceManager object 210 can also add 
methods to enable persistence functionality, such as a method to delete 
application objects, a method to call an adapter object 212, a method to store 
application objects, and a method to retrieve application objects. The 
PersistenceManager object 210 loads configuration data from the manager 
configuration 214, referred to as the PersistenceManager configuration 214. 

[0071] The software architecture 100 provides persistence adapter classes for the 
persistence service 208. In this implementation, the software architecture 100 
provides an adapter class called the BasePersistenceAdapter class 900 that 
extends the provided BaseAdapter class 302 and can be used as a superclass 
for the persistence adapter objects 212. A Persistence Adapter interface 304 is 
provided for the BasePersistenceAdapter 900 to establish methods, implemented 
by the adapter objects 21 2, that enable communications with the manager 
object 210 (i.e., PersistenceManager object 210), as well as whatever persistence 
mechanism the software employs. The BasePersistenceAdapter 900 can also 
load configuration data from the PersistenceAdopter configuration 216. 

[0072] Next, the software architecture 100 provides two subclasses for the 
BasePersistenceAdapter class 900, a BaseDelegatePA class 902 and a 
BaseCompositePA class 904. The BaseDelegatePA class 902 is a superclass for 
delegate persistence adapters that can be combined together by composite 
persistence adapters. The BaseCompositePA class 904 functions as a superclass 
for the composite persistence adapters, which can combine multiple delegate 
persistence adapters. 
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[0073] The BaseDelegatePA class 902 can have a number of subclasses that are 
used to instantiate adapter objects 21 2 for use in the persistence service 208. For 
instance, a DaoPA class 906 extends the BaseDelegatePA class 902 and utilizes 
data access objects for the persistent storage of a business object. Similarly, an 
EntityPA class 908 utilizes entity EJBs for the persistent storage of a business object, 
and a StrategyPA class 910 utilizes strategy session EJBs for the persistent storage 
of a business object. Application component interfaces 306 can be 
implemented to enable communications between adapter objects 212 
instantiated from these subclasses and their associated application components 
202. 

[0074] The BaseCompositePA class 904 can also have a number of subclasses 
that are used to instantiate adapter objects 21 2 for the persistence service 208. 
For instance, the BaseCompositePA class 904 can include a 
DAOEntityStrategyPA class 912 to utilize data access objects, entity EJBs, and 
strategy session EJBs for the persistent storage of a business object, a 
DAOLEntityStrategyPA class (not shown) to utilize data access objects, local 
entity EJBs, and strategy session EJBs for the persistent storage of a business 
object, a DAOStrategyPA class (not shown) to utilize data access objects and 
strategy session EJBs for the persistent storage of a business object, an 
EntityStrategyPA class (not shown) to utilize both entity EJB and strategy session 
EJBs for the persistent storage of a business object, and a FastLaneReaderPA 
class (not shown) to utilize data access objects, entity EJBs, and strategy session 
EJBs for the persistent storage of a business object, except when handling 
collections. In one implementation, application components 202 can be 
provided to perform object relational mapping between a business object and 
the persistence storage. Other application components 202 can contain other 
logic needed for business object persistence. 

[0075] The software architecture 100 can provide further manager/adapter 
classes and architecture services in addition to the ones described above. 
Figure 10 is a UML diagram of one implementation of a logging architecture 
sen/ice provided by the software architecture 100. Logging functionality outputs 
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nnessages fronn the application for nnany purposes including debugging, error 
handling, and infornnational purposes. The logging service can log nnessages of 
different severities to sonne standard repository. 

[0076] As discussed above, the softvs^are application 100 provides a 
BaseMonager class 300 and a BaseAdapter class 302 fronn which nnanager and 
adapter objects or classes can be generated. In the logging service, the 
software architecture 100 instantiates a LogManager object 210 fronn the 
BaseMonager class 300. The LogManager object 210 sen/es as the manager 
object 210 of the logging service and loads configuration data fronn a 
LogManager configuration 214. The LogManager class can define nnethods to 
log a nnessoge with the debug severity and to log a nnessoge with the error 
severity. 

[0077] The software architecture 100 also generates a BaseLog Adapter class 
1000 fronn the BaseAdapter class 304. The BaseLog Adapter class 1000 
innplennents a LogAdopter interface 304 and loads configuration data fronn a 
LogAdopter configuration 21 6. Adapter objects 21 2 can be instantiated from 
the BaseLogAdapter class 1000. For instance, a SystemOutPrintLA object 212 
and a FileLA object 212 can be instantiated. The SystemOutPrintLA object 212 
logs all messages to standard output and the FileLA object 212 logs all messages 
to a file. 

[0078] Figure 1 1 is a UML diagram of one implementation of an application state 
management architecture service provided by the software architecture 100. 
This sen/ice is used to cache and retrieve data, for example, to manage any 
content that needs to be stored on the server for the convenience of retrieving it 
at a later time. The software application 100 again provides a BaseMonager 
class 300 and a BaseAdapter class 302 from which manager and adopter 
objects or classes con be generated. In the application state management 
sen/ice, the software architecture 100 instantiates a ContentMonoger object 210 
from the BaseMonager class 300. The ContentMonoger object 210 serves as the 
manager object 210 of the application state management service and loads 
configuration data from a ContentMonager configuration 214. The 
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ContentManager class can define methods to retrieve content and to store 
content. 

[0079] The software architecture 100 also generates a BaseContent Adapter class 
1 100 from the BaseAdapter class 304. The BaseContentAdapter class 1 100 
implements a ContentAdapter interface 304 and loads configuration data from 
a ContentAdapter configuration 21 6. Subclasses to the BaseContentAdapter 
class 1 100 can be provided to instantiate adapter objects 212, or adapter 
objects 212 can be instantiated directly from the BaseContentAdapter class 
1100. In an implementation, the software architecture provides the following 
adapter classes or adapter objects 21 2: a CookieCA adapter class to deal with 
content stored or retrieved from cookies; an EJBSessionCA adapter class to store 
and retrieve content from a session EJB; a FileProxyCA adapter class to allows 
access to files for the business application; an HttpRequestCA adapter class to 
store and retrieve content from an HTTP request; an HttpSessionCA adapter class 
to store and retrieve content from an HTTP session (not shown); and a 
MapApplicationCA adapter class to store and retrieve content in a application 
wide repository backed by a Java Map collection object. Using the application 
state management service masks the intricacies of dealing with the underlying 
storage mechanisms. 

[0080] Figure 12 is a UML diagram of one implementation of a data marshalling 
architecture service provided by the software architecture 100. Data 
marshalling handles the conversion of data from one format to another. Each 
adapter object 212 in the data marshalling service can have a different 
mechanism for converting data, and can support one or more types of 
conversions. A typical example of a conversion is converting data from objects 
to XML. 

[0081] As before, the software application 100 provides a BaseManager class 
300 and a BaseAdapter class 302 from which manager and adapter objects or 
classes can be generated. In the data marshalling service, the software 
architecture 100 instantiates a MappingManager object 210 from the 
BaseManager class 300. The MappingManager object 210 serves as the 
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manager object 210 of the data marshalling sen/ice and loads configuration 
data from a MappingManager configuration 214. The MappingManager class 
can define methods such as for extracting information contained in an object 
and for populating on object. 

[0082] The software architecture 100 also generates a BaseMappingAdopter 
class 1 200 from the BaseAdapter class 304. The BaseMappingAdopter class 1200 
implements a MappingAdapter interface 304 and loads configuration data from 
a MappingAdapter configuration 216. The software architecture 100 can 
instantiate an adapter object 212 from the BaseMappingAdopter class 1200, 
such as a MappingAdapter object 212. The MappingAdapter object 212 con 
perform XML data binding for both marshaling and unmorsholing, for instance, 
marshaling objects into their XML representation and unmorshoiing XML 
representations to generate and/or populate objects. The MappingAdapter 212 
loads configuration data from a MappingAdapter configuration 216 and 
communicates with application components 202 through a Mapper application 
component interface 306. 

[0083] In on implementation, the software architecture 100 con provide one 
adapter class for handling the marshaling and unmorshoiing of business objects 
and business object collections, one adopter class for handling the marshaling 
and unmorshoiing of event objects containing business objects, business object 
collections, application exceptions, and process names, one adopter class for 
handling the marshaling and unmorshoiing of jovo.util.Mop objects, one adopter 
class to provide a default adopter implementation for the MappingManager 
and to function as a superclass for custom adapter objects 212 associated with 
the MappingManager, one adopter class to use session or entity EJBs for the 
generation and obtaining of primary keys for business objects, and one adapter 
class to use session EJBs for the generation and obtaining of primary keys for 
business objects. 

[0084] Figure 13 is a UMl diagram of one implementation of a key management 
architecture service provided by the software architecture 100. Key 
management handles the generation of unique identifiers (i.e., keys) for relevant 
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objects. Each adapter object 212 used in this service con use a different 
nnechanisnn to generate unique keys. The software application 100 again 
provides a BoseMonager class 300 and a BaseAdapter class 302 from which 
nnanager and adapter objects or classes can be generated. In the key 
managennent sen/ice, the software architecture 100 instantiates a KeyManager 
object 210 fronn the BaseManager class 300. The KeyManager object 210 serves 
as the nnanager object 210 of the key managennent service and loads 
configuration data from a KeyManager configuration 214. The KeyManager 
class can define methods to construct a new primary key of the correct type for 
the object with a valid value and to return the field name that is used by the 
software application to contain the primary key value when marshaling and 
unmarsholing data. 

[0085] The software architecture 100 also generates a BaseKey Adapter class 
1300 from the BaseAdapter class 304. The BaseKey Adapter class 1300 
implements a Key Adapter interface 304 and loads configuration data from a 
KeyAdapter configuration 216. The software architecture 100 can instantiate an 
adapter object 212 from the BaseKey Adapter class 1300, such as an 
EntitySessionKA 212 that uses either session or entity EJBs for the creation and 
obtaining of Primary Keys for business objects, a HLStringKA 212 that uses session 
EJBs for the creation and obtaining of primary keys for business objects, and a 
HLIntegerKA 212 that also uses session EJBs for the creation and obtaining of 
Primary Keys for business objects. 

[0086] Figure 14 is a flowchart illustrating one implementation of how the client 
retrieves business functionality from the software architecture. The client begins 
by calling a manager object in the software architecture (step 1 400). If no 
manager object exists at the moment the business application framework calls 
into the software architecture, a manager object can be instantiated from the 
appropriate manager class. 

[0087] Once the manager object is instantiated, the manager object loads and 
caches the manager configuration data instructing the manager object on how 
to delegate different calls from the business application framework to the 
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appropriate adapter object (step 1402). The nnanager object parses the call 
and selects an adapter class based at least in part on the instructions in the 
manager configuration, and the naanager object instantiates and caches an 
adapter object from the selected adapter class (step 1404). The manager 
object calls the instantiated adapted object and delegates to it the call from 
the client (step 1406). 

[0088] The adapter object, after it has been instantiated, loads and caches the 
adopter configuration data instructing the adapter object on how to handle 
different colls from the client (step 1408). The adopter object instantiates and 
caches the appropriate application component or components to handle the 
request from the client based on the data in the adopter configuration (step 
1410). The application components con be provided as classes by the user; 
application components con then be instantiated from the appropriate class 
when needed. Alternatively, the application components can be provided as 
objects and do not have to be instantiated by the adapter object. 

[0089] The adopter object can execute any technical code that is required by 
the request from the client (step 1412). The adopter object then colls the 
application component (step 1414), and the application component executes 
the business code for which it was developed (step 1416). The execution of the 
business code generally results in some form of output being returned to the 
client. 

[0090] Figure 15 is a flowchart describing one implementation of the operation of 
the navigation sen/ice 204. The navigation service displays the graphical user 
interface (GUI) to on end-user and controls the user interface flow, known as 
navigation. In this implementation, the navigation service instantiates a 
NavigotionMonoger object as described above, and implements the 
NovigotionAdapter interface. The NovigotionMonager object con instantiate 
on adopter object such as a NovigotionAdapter object. Application 
components, such as application components used for the user interface (e.g., 
application components to generate HTML pages and JSP pages), can be 
instantiated by the adapter object. 
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[0091] When a request fronn an end-user is received fronn the client, it is sent as a 
call into the navigation service and received by the NavigationManager object 
, (step 1500). The NavigationManager object loads and reads the navigation 
configuration (step 1502), and based at least in port on the instructions in the 
configuration, selects the NavigationAdapter to handle the call fronn the client 
(step 1504). 

[0092] The NavigationManager object loads and caches the selected 
NavigationAdapter object (step 1506), and passes the call to the 
NavigationAdapter object. The NavigationAdapter object then loads and reads 
the navigation configuration (step 1508). In sonne implennentations, the 
configuration for the nnanager is different than the configuration for the 
adapters, while in other innplennentations the some configuration can be used 
for both. Next, the NavigationAdapter object, based at least in part on the 
instructions in the configuration, determines which business process is being 
requested by the call (step 1510). 

[0093] To execute the business process, the NavigationAdapter object calls the 
BusinessProcessManager fronn the business process sen/ice and passes the call 
from the client on to the BusinessProcessManager object (step 1512). The call 
from the client is a request that generally contains the name of the business 
process to execute and the user data necessary to carry out the process. 

[0094] After the BusinessProcessManager object processes the call, it returns 
data to the NavigationAdapter object (step 1514). The NavigationAdapter 
object reads the navigation configuration that contains rules specifying which 
user interface component to display based on the data returned from the 
BusinessProcessManager object (step 1516). Based on this data, the 
NavigationManager object displays the appropriate user interface component 
to the client (step 1516). 

[0095] Figure 16 is a flowchart describing one implementation of the operation of 
the business process sen/ice 206. As explained above, the business process 
service manages and executes the business logic of the application. In this 
implementation, the business process service can instantiate and use a 
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BusinessProcessManager object, and can innplennent a BusinessProcessAdapter 
interface as its adapter interface. The business process sen/ice can instantiate 
adapter objects as required, the EJBBusinessProcessAdapter and the 
WebBusinessProcessAdapter being two examples. The business logic 
requirements map to business process steps which implement the business logic 
and are executed by the BusinessProcessManager object. 

[0096] The BusinessProcessManager is generally called from another software 
component, such as the navigation service, to execute a named business 
process (step 1 600). For example, if the business process is for banking 
transactions, the named business process can be called TransferFundsProcess. 
The incoming call generally includes the name of the business process to 
execute and the data required to execute the process. The 
BusinessProcessManager object reads the business process sen/ice configuration 
(step 1602) and selects the appropriate adapter object (e.g., the 
EJBBusinessProcessAdapter object) specified for the business process requested 
in the call (step 1 604). The configuration provides instructions used by the 
BusinessProcessManager object to select and instantiate the appropriate 
adapter object. 

[0097] The BusinessProcessManager loads and instances the selected adapter 
object (step 1606). The BusinessProcessManager then calls that adapter object 
and passes on the name of the requested business process and the data 
required to execute the process to the adapter object (step 1608). The adapter 
object reads the business sen/ice configuration and finds the definition for the 
requested business process (step 1610). The configuration also enables the 
adapter object to locate and retrieve the appropriate application components 
specified for the named business process (step 1 610). The adapter object then 
loads and instances the appropriate application components needed to carry 
out the requested business process (step 1612). For example, if the requested 
business process is the TransferFundsProcess mentioned above, the appropriate 
application components could be a DebitAccountStep object and a 
CreditAccountStep object. 
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[0098] The adapter object calls each application connponent sequentially 
passing the data (step 1614), and the application connponents execute the 
requested business functionality (step 1616). For example, in the 
TransferFundsProcess, the DebitAccountStep object can rennove nnoney fronn a 
first account, and the CreditAccountStep object can add nnoney to a second 
account. 

[0099] Figure 17 is a flowchart describing one innplennentation of the operation of 
the persistence service 208. The persistence service perfornas persistence 
operations (i.e., create, retrieve, update, and delete) on the objects/data of the 
business application. Different persistence adapters are provided for different 
technical persistence nnechanisnns. In this innplennentation, the persistence 
sen/ice can instantiate and use a PersistenceManager object, and can 
implennent a PersistenceAdapter interface. The persistence service can also 
instantiate adapter objects, such as a DooPA object, an EntityPA object, a 
StrategyPA object, an EnnailPA object, a FastLaneReaderPA object, as well as 
many other adapter objects. The application components that can be called 
by these adapter objects can include a Dao object, a StrategyEJB object, and 
on EntityEJB object. 

[0100] In the persistence service, the PersistenceManager is generally called by a 
software component, such as a business application component from the 
business pi-ocess service (step 1700). The call includes the appropriate data 
needed to carry out the persistence functionality. The PersistenceManager 
object reads persistence service configuration (step 1 702) and selects the 
appropriate persistence adapter object based on the data that is passed in and 
based on the instructions in the configuration (step 1704). The 
PersistenceManager object then loads and instances the selected adapter 
object (e.g., the DaoPA object) (step 1706), and passes the necessary data on 
to the adapter object (step 1 706). 

. [0101] The persistence adapter object loads and reads the persistence 
configuration (step 1 708) and selects the appropriate application component to 
handle the requested persistence functionality (step 1710). The persistence 
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adapter object then instances and calls the application connponent and passes 
the data on to the application connponent (step 1712). The return data fronn the 
application connponent after the functionality is carried out is passed back up to 
the caller of the PersistenceManager (step 1714). 

[0102] The invention can be innplennented in digital electronic circuitry, or in 
computer hardware, firnnware, software, or in combinations of them. The 
invention can be implemented as a computer program product, i.e., a 
computer program tangibly embodied in an information carrier, e.g., in a 
machine readable storage device or in a propagated signal, for execution by, 
or to control the operation of, data processing apparatus, e.g., a programmable 
processor, a computer, or multiple computers. A computer program can be 
written in any form of programming language, including compiled or interpreted 
languages, and it can be deployed in any form, including as a stand alone 
program or as a module, component, subroutine, or other unit suitable for use in 
a computing environment. A computer program can be deployed to be 
executed on one computer or on multiple computers at one site or distributed 
across multiple sites and interconnected by a communication network. 

[0103] Method steps of the invention can be performed by one or more 
programmable processors executing a computer program to perform functions 
of the invention by operating on input data and generating output. Method 
steps can also be performed by, and apparatus of the invention can be 
implemented as, special purpose logic circuitry, e.g., an FPGA (field 
programmable gate array) or an ASIC (application specific integrated circuit). 

[0104] Processors suitable for the execution of a computer program include, by 
way of example, both general and special purpose microprocessors, and any 
one or more processors of any kind of digital computer. Generally, a processor 
will receive instructions and data from a read only memory or a random access 
memory or both. The essential elements of a computer are a processor for 
executing instructions and one or more memory devices for storing instructions 
and data. Generally, a computer will also include, or be operatively coupled to 
receive data from or transfer data to, or both, one or more mass storage devices 
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for storing data, e.g., magnetic, nnagneto optical disks, or optical disks. 
Infornnation carriers suitable for ennbodying computer program instructions and 
data include all forms of non volatile memory, including by way of example 
semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory 
devices; magnetic disks, e.g., internal hard disks or removable disks; magneto 
optical disks; and CD ROM and DVD-ROM disks. The processor and the memory 
can be supplemented by, or incorporated in special purpose logic circuitry. 

[0105] The software architecture of the invention therefore separates the difficult 
technical challenges associated with the production of a business application. 
As described herein, the software architecture accomplishes this by defining 
how to develop business components in a way that is independent of the 
underlying technologies. Developers who use the software architecture of the 
invention can invest significantly less time becoming familiar with distributed 
infrastructure solutions, and can spend more time concentrating on 
implementing their application-specific business logic. In such a case, these 
developers need only to understand the business-level components. 

[0106] The invention has been described with reference to specific 
implementations. Other implementations of the invention will be apparent to 
those of ordinary skill in the art. For example, the functionality of the software 
architecture 100 can be used for any type of software application, not just 
business applications. It is, therefore, intended that the scope of the invention 
not be limited to the implementations described above. 
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